Product Ops Overview

As Product School says in their survey article trying to define what Product Ops is: “Product Ops operates differently at every company.”  Which might be true, but isn’t very helpful.  

From my own interactions with companies implementing or exploring Product Ops, I have found no fewer than six distinct definitions.

So the first and most obvious question is why so many different definitions?  

My theory is that while the term emerged as a roughly parallel concept to DevOps, the original concept of DevOps refers primarily to tools and technology to empower engineers to accelerate their code into production, but I haven’t encountered anyone trying to do roughly analogous tooling for product managers (other than tool vendors of course).

I think that’s partly because there are already plenty of off-the-shelf solutions for the major tools like roadmap and OKR tools, but mainly because unlike engineering, for most things PM’s do, it’s simply not a function of the tools, so the original meaning of DevOps doesn’t really apply so well to product management.

That said, the concept of empowering product managers to do good work, much like we empower engineers, resonates very easily.  So it creates this nice big placeholder called “Product Ops” that is general enough, and fashionable enough, that it’s tempting for a company to use it to address perceived organizational needs related to product.

Regardless of whether my theory is correct, the first thing to realize is that if a company says “we have Product Ops,” that’s a fairly meaningless statement today.

But please don’t misunderstand me.  As you might imagine, I love the concept of empowering product managers and product teams to help them do good work, and I do think there are very good ways to leverage the potential of Product Ops to better empower product managers and product teams.

So in this article I want to try to encourage companies to both be wary of the unhelpful definitions, but also to consider embracing what I think is a valuable and helpful definition of Product Ops.

But before I share my observations, I need to provide a few caveats:

First, remember that the focus of my work is on those product companies, product leaders and product teams that are trying to work like the best companies.  I make no apology for that, as there are plenty of people out there who cater to the rest.  But as you’ll see, many of the problematic definitions of product ops out there are a reaction to the deeper issues, especially of feature teams, and slapping the label “Product Ops” on a fundamentally limited model won’t fix those issues.

Second, there are defenders out there for each of the definitions of Product Ops that I describe, and I encourage you to listen to their arguments, and draw your own conclusions.

Third, despite so many different definitions, I should warn you up front that I have yet to find anything that is actually new.  And I don’t mean new as in the last couple of years.  I mean new as in the last couple of decades.  At least as practiced in good product companies.  But don’t take that to mean there is no value in Product Ops as a concept, as I believe there is, and I’ll make that case below.

Here are the various definitions I have personally encountered, presented in the order that I consider most damaging, to most valuable:

The Reincarnated PMO Model

“At our company, Product Ops facilitates planning activities – long range planning, roadmap planning, and portfolio planning. We also facilitate the execution by coordinating and tracking activities across the organization from launch to sunsetting. We are responsible for putting standard operating procedures and governance in place around our unified lifecycle.  We are the first point of engagement for stakeholder requests, and we manage timelines and deliverables.” – VP Product Ops for large hardware appliance company

In many companies, when Agile came in, the command and control style PMO (Program Management Office) was displaced. However, they’ve been seeking a way back in for years.  One very clear manifestation of this is the rise of SAFe.  

But the more recent manifestation, as in the quote above, and the one I wrote about in the recent article Process People, is using Product Ops as a Trojan Horse to bring back in the people, practices and especially the command and control mindset of the old style PMO.

Am I being paranoid here?  Maybe.  But the reason for this is no mystery.  Many old-school CEO’s and companies crave the perceived predictability and control of the old PMO model – that’s a big reason they are attracted to SAFe.  But more generally, I am constantly worried about becoming a Day 2 organization.

Thankfully not all PMO people have this problematic mindset.  I know many exceptionally strong and truly helpful program managers, and they are essential for many types of very complex products – especially devices.  The problematic behavior I’m  referring to is the top-down, command and control mindset.

I hope I don’t have to reiterate all the reasons why I’m no fan of this model.  All I’m really pointing out here is that in some companies, they are literally defining Product Ops just as companies in the pre-Agile era used to define a PMO.

The Two-in-a-Box PM Model 

“While a Product Manager owns the development of the product (aka, the person who Builds The Thing) a Product Operations Manager handles the day to day tasks involved with development (aka, the person who Makes It Easier to Build The Thing).” – Product School

I feel like I have been playing “whack-a-mole” on this problem for literally twenty years.  

This problem pops up under so many different names.  Having both a Product Manager and a Product Owner on a product team.  Or having a Product Manager and a Business Analyst.  Or having an Outbound and an Inbound Product Manager.  Or having a Product Manager and an Associate Product Manager.  Or, the newest incarnation, having a Product Manager and a Product Ops Manager on each product team.

I realize that the root cause of this persistent issue is that so many product managers feel like they have too much work to do, and too many responsibilities.  

Knowledgeable coaching is normally the key to overcoming this issue, but combined with the next issue – where their manager is not willing or able to provide the necessary coaching – and people understandably look to split up the job to be more manageable.

But what these people don’t realize are the long-term consequences impacting the product manager’s ability to provide the contribution their product team depends on them for.  I’ve written many times about the negative consequences of splitting this critical role.  

But I recognize that I need to write more about this, as so many people do not really grok the need for the ongoing and hands-on aggregation and assimilation of information and insights so essential to an effective product manager.

Now it’s important to be clear here about what is important to be part of the PM responsibilities and what is not.

For example, in most medium size companies, and nearly every large product company, there are teams of people to help product managers and designers answer questions quantitatively (e.g. data analysts), and people to help product managers answer questions qualitatively (e.g. user researchers).  We’ll talk more about these important roles below.

It’s critical that the PM still owns these decisions, and is not delegating them, but these people provide critical and essential help.

The Delegated Product Leader Model 

“Our company relies on Product Ops to ensure our product managers learn the necessary skills, select and understand the appropriate tools, know when and how to run experiments, learn how to interpret and leverage data, and to connect the dots between the activities of the various product teams.” – Director of Product Operations at large e-commerce company

Managers of product managers are there to enable their product managers to do good work.  

Yet isn’t that also the general purpose of Product Ops?  

In practice, while Product Ops can definitely help when done well (as will be argued below), one unfortunate consequence is when the product leaders think they can delegate the responsibility for coaching product managers and/or developing the product strategy to Product Ops.

Very related to the Two-in-a-Box PM model (and in my view the major root cause of weak product managers) is the situation where the product leaders are not willing or able to do their job, especially when it comes to coaching and product strategy.

In companies where the product leaders are primarily people managers (in the HR sense) and they can’t or won’t provide the necessary coaching or the strategic context, that creates a significant vacuum in terms of product leadership.

And in some companies, they hope that Product Ops can fill that vacuum.

The problem of weak product leadership is not a new one.  

When the product leaders are not willing or able to coach and develop their people, the people look elsewhere for help.  Sometimes to internal or external training programs or certifications.  Sometimes to mentorship programs.  These can be helpful, but nothing even close to having a manager that is taking personal responsibility for developing your skills and career.

Similarly, you may also have seen companies in the past that would create a separate product strategy team, often staffed with former management consultants. The problem then, as with now, is that these people would not be close enough to the ongoing discovery work on the ground (in the product teams) to gain the necessary insights to power good product strategies, and in any case, the strategy people weren’t well-respected enough by the product teams to pay much attention to what they came up with anyway.

Again, we do count on the existence of data and customer insights teams to help those product leaders to do their jobs, so there’s no expectation that they are doing all that work themselves.  

However, and this is absolutely critical: it is the ongoing aggregation and assimilation of those insights, combined with daily interactions with the product teams, that enables strong product leaders and strong product strategies.

But more generally, when the manager doesn’t take personal ownership and responsibility for the skills of her product managers, then this either gets dropped or gets delegated, and the result is too often weak product managers, and inevitably weak product teams.

The bottom line is that there really isn’t a good substitute for capable, engaged product leaders working one on one with their product managers not just to understand the theory, but to learn the actual practice and nuance of strong product.  If that’s the real problem, then that is what needs to be fixed.

Production Operations Rebranding Model 

“A PM’s job doesn’t end at launch… But at many companies, this is where the [product ops] job really starts… they provide value… by making sure that things keep running smoothly.” – Product School

I know the phrase sounds very similar, but “production operations” has a very specific and important meaning in many companies.

Some readers will immediately know what I’m referring to and others won’t, because of the nature of their products.  

Let me give a clear example from a favorite product of mine: Guardian’s Eyewitness.  Even more impressive than the product was that it was done by a 200-year old company, in only 7 weeks. You can read the origin story here, but the product was a photo-journalism app for the then-new iPad, and the product told the news through photos, which required daily coordination between a photo editor, news journalist, and editorial.

While the product team created tools to support this daily production process, there is always a certain amount of ongoing production operations (literally “ensuring the product is running properly in production”).

It’s not hard to imagine that if the business/product operations issues grow large enough, it can place a large demand on the time of the product manager.  Partly that’s good because then the PM is motivated to invest in further automation.  But in many cases, it can make sense to designate a dedicated production operations person.

The problem is that this job function has never had a great title, and so it wasn’t a surprise to me to find some companies that have appropriated the title “Product Ops” for this.  

And to be clear, it is an important role for many products, and if rebranding the Production Operations role to Product Ops helps these companies attract and retain strong people for the role, then that is understandable to me.

About the only downside I can see is that over time, it will likely create some confusion for future employers trying to figure out what relevant experience the candidate with this title on their resume or profile actually has.

The Product Marketing Manager Rebranding Model 

“At our company, Product Ops covers two main activities: synthesizing ongoing customer feedback from sales, services and support, and coordinating launch-related activities including beta and early release programs.  Product Marketing initially tried to do this work, but they have not had the bandwidth, and in many cases, the necessary skills.”  – VP Product Ops for Enterprise Software Company

Product Marketing has always been a tough job, but for many products today, especially in the B2B space, the job has grown in difficulty at least as much as the product manager job has.

Launch related activities can be extensive with customer discovery programs, beta programs, sales, services and marketing training; continuous product go-to-market testing; and then the customer feedback needs to be aggregated and analyzed by the various sales channels.

Conventional product marketing can find it difficult to keep up with this demand and to attract talent capable of the depth and breadth required, so in at least some companies, the role has been expanded and effectively rebranded to attract a hands-on, relatively technical, true partner for the product manager focused on the product marketing side of the equation.

The jury is still out for me on this.  I am sympathetic to the need for this one because I have also seen this issue many times.  Maybe this is a case where a rebranding is necessary to make the job more attractive to the right type of people.

In any case, this is critically important work, and by whatever title, it’s essential that it be done well.

As with production operations rebranding, there is a minor risk that future employers will struggle to understand relevant experience of candidates with experience in this model.  And of course, this approach may introduce tension with the product marketing team.

The Force Multiplier Model

Thus far I’ve described five very different definitions of Product Ops – three that I consider old problems re-emerging with fresh lipstick, and two that are existing roles that have been rebranded to help make them more attractive to the right talent.

Now I’d like to describe the model of Product Ops that I personally hope companies will consider adopting. 

I should say here that the definition I’m encouraging here is heavily influenced by how Melissa Perri defines Product Ops in her book Escaping The Build Trap, at least to the best of my understanding.

She defines three pillars (I am paraphrasing here to use the terms that my readers have seen me use to describe these concepts):

• Quantitative Insights 
• Qualitative Insights 
• Tools and Best Practices Evangelism

– Quantitative Insights Team

For more than 20 years good product companies have had data insights teams (by various names) available to help product teams make data-informed decisions.  

This is especially important with data because it’s essential that you have a single source of truth about data (you don’t want every product manager defining and interpreting KPI’s in their own way), and because there are often multiple tools required to access the various data sources.

It’s important to point out that this needs to be an enablement team.  In other words, the data insights team doesn’t do the analysis as a service.  Rather, they enable the product teams, including creating self-service tools, and generally raising the data IQ of the broader product organization.

The problem is that this team often struggles to find the right home in the organization.  I have seen this team located as part of finance, as part of engineering, as part of sales or business operations, as part of product, and sometimes just on its own as a bit of an orphan.

The reason I like promoting this team into Product Ops is to ensure all product teams always have direct access to these essential people.

– Qualitative Insights Team

Similar to the quantitative insights team, strong product companies have had qualitative insights teams for several decades.  Sometimes the team is just a small number of user researchers, but even a very small user research team can have an outsized impact.

As with the data insights team, In the case of user research, this is not about doing the research for the product teams, but rather, coaching and enabling the product teams to do good research and learn first-hand, as well as providing the infrastructure for ongoing customer testing.  

Usually the team is part of the UX / Product Design organization, but sometimes it can be found as part of marketing, and occasionally in fairly random locations.  I’ve mainly seen the team called user research, customer insights, or market insights.

As with the Quantitative Insights team, I like the idea of promoting this function to a pillar of Product Ops.  

One way or another, every product team needs to be able to answer questions both quantitatively and qualitatively, but keep in mind that these insights teams are there to help product teams and product leaders to make informed decisions, not to make those decisions for them.

– Tools and Best Practices Evangelism

This is the pillar where, in my experience, things are most likely to go sideways if you are not very intentional about the specific people you place in this role.  Of course that’s true to a degree with most roles, but few roles have the ability to impact the organization’s product culture as much as this one – for better or for worse.

As I described in my last article, in many of my favorite companies, they would take one of the most respected, senior product managers, often a principal product manager, and ask that person to help with raising the skills of the company’s product managers.

This might include development of an onboarding program or other forms of training, coaching on advanced discovery techniques, tool selection, creating and sharing relevant examples, and otherwise diving into complex areas to help other product managers and product teams.

I have always loved using principal product managers and principal designers for these roles because first, by definition, these people have very deep and relevant product experience; and second, this helps the group effectively become a force multiplier.

Promoting this into Product Ops makes this responsibility more explicit, with potentially more time dedicated to this.

Especially at scale, it’s useful to have one or more exceptionally strong people to lead product manager and product designer onboarding and training, constantly working to raise the bar on the skill level of the organization and ensure consistently strong teams.  And overall to be a resource to the product teams for things like best practices and coaching on especially difficult problems in discovery.

One particular process worth calling out is the quarterly planning process, which in a large organization, there is a lot of tracking, alignment and coordination work to be done, and having an experienced person or small group to assist can be helpful to all involved.

Much of this is necessarily on the product leaders (they need to be responsible for the product strategy and team objectives).

Again, with the wrong people in this role it can spin out of control, and “process becomes the thing.”  We want the planning process driven by the product leaders, and not the other way around.

Another reason I like principal product managers and designers in this role is that they understand that standardizing best practices sounds good in theory, but if not based on judgment and experience, it can lead to imposing one way of doing things on different teams where that way often does not make much sense.

– Organization

I like to think of this Force Multiplier Model as having a Product Ops function at the same level as Product Management and Product Design.  Product Ops is there to serve as a force multiplier to product managers, product designers and for certain activities, the product marketing managers.You could argue that this is just moving some existing people around, but one thing we learn in product and product marketing is that smart bundling and packaging can often have a remarkable impact.

To me, this particular combination of quantitative and qualitative insight services, along with best practices evangelism, makes for a more significant organizational impact, and a more attractive role in the organization for the right people to staff these areas.

It’s worth emphasizing that each of those three components of Product Ops represent three very different skill sets, and they are also non-trivial skill sets.  The Force Multiplier Model depends on highly skilled people in these areas, otherwise they can have the opposite effect: reducing the effectiveness of the product teams that depend on them.

In too many companies I see, they are taking very junior people, sometimes people with no directly relevant experience, and putting them in this very high-impact position.  Please don’t do that.  It’s effectively the same problem as when companies send their product managers to training by people that have never done the actual job.

Summary

While I know many companies that have long had the three pillars of what I’m calling here the Force Multiplier Model of Product Ops, I don’t know many yet that have brought them together organizationally under the Product Ops umbrella, but I’m hoping to see more try, and if you do, I hope you’ll let me know how it goes.

More generally, these six models I’ve described are just the main ones I’ve personally seen (I have encountered a few others but they seem like true one-off outliers).  I fully expect that there are others out there that I have yet to encounter.  If your company has implemented a different definition of Product Ops from the ones I’ve described here, I hope you’ll share that definition with me, along with your experiences.

In any case, given the range of different approaches to Product Ops, I expect that we’ll continue to see ambiguity until this settles down, and a particular model becomes more prevalent.  I’m just hoping it’s a model that represents a true step forward.

Special thanks to Chris Jones for his help with this article.